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Abstract 


When set up through an explicit path, dynamic Multi-Segment 
Pseudowires (MS-PWs) may be required to provide a simple solution for 
1:1 protection with diverse primary and backup MS-PWs for a service, 
or to enable controlled signaling (strict or loose) for special MS- 
PWs. This document specifies the extensions and procedures required 
to enable dynamic MS-PWs to be established along explicit paths. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
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1. Introduction 


Procedures for dynamically establishing Multi-Segment Pseudowires 
(MS-PWs), where their paths are automatically determined using a 
dynamic routing protocol, are defined in [RFC7267]. For 1:1 
protection of MS-PWs with primary and backup paths, MS-PWs need to be 
established through a diverse set of Switching Provider Edges (S-PEs) 
to avoid any single points of failure at the PW level. [RFC7267] 
allows this through BGP-based mechanisms. This document defines an 
additional mechanism that allows Source Terminating Provider Edges 
(ST-PEsS) to explicitly choose the path that a PW would take through 
the intervening S-PEs. Explicit path routing of dynamic MS-PWs may 
also be required for controlled setup of dynamic MS-PWs and network 
resource management. 


Note that in many deployments the ST-PE will not have a view of the 
topology of S-PEs and so the explicit route will need to be supplied 
from a management application. How that management application 
determines the explicit route is outside the scope of this document. 


Dutta, et al. Standards Track [Page 2] 


RFC 7392 MS-PW Explicit Routing December 2014 


2. Requirements Language and Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


This document uses the terminology defined in [RFC7267], [RFC4447], 
and [RFC5036]. 


The following additional terminology is used: 


Abstract Node: A group of nodes (S-PEs) representing an explicit hop 
along the path of an MS-PW. An abstract node is identified by an 
IPv4, IPv6, or S-PE address. 


3. Explicit Path in MS-PW Signaling 


This section describes the Label Distribution Protocol (LDP) 
extensions required for signaling explicit paths in dynamic MS-PW 
setup messages. An explicitly routed MS-PW is set up using a Label 
Mapping message that carries an ordered list of the S-PEs that the 
MS-PW is expected to traverse. The ordered list is encoded as a 
series of Explicit Route Hop TLVs (ER-Hop TLVs) encoded in an ER-TLV 
that is carried in a Label Mapping message. 


3.1. S-PE Addressing 


An S-PE address is used to identify a given S-PE among the set of 
S-PEs belonging to the Packet Switched Networks (PSNs) that may be 
used by an MS-PW. Each S-PE MUST be assigned an address as specified 
in Section 3.2 of [RFC7267]. An S-PE that is capable of dynamic 
MS-PW signaling, but has not been assigned an S-PE address, and that 
receives a Label Mapping message for a dynamic MS-PW MUST follow the 
procedures in Section 3.2 of [RFC7267]. 


3.2. Explicit Route TLV (ER-TLV) 


The ER-TLV specifies the path to be taken by the MS-PW being 
established. Each hop along the path is represented by an abstract 
node, which is a group of one or more S-PEs, identified by an IPv4, 
IPv6, or S-PE address. The ER-TLV format is as per Section 4.1 of 
[RFC3212]. 


The ER-TLV contains one or more ER-Hop TLVs as defined in 
Section 3.3. 


Dutta, et al. Standards Track [Page 3] 


RFC 7392 MS-PW Explicit Routing December 2014 


3.3. Explicit Route Hop TLV (ER-Hop TLV) 
The contents of an ER-TLV are a series of variable-length ER-Hop 
TLVs. Each hop contains the identification of an "abstract node" 
that represents the hop to be traversed. The ER-Hop TLV format is as 
specified in Section 4.2 of [RFC3212]. 
[RFC3212] defines four ER-Hop TLV Types: IPv4 Prefix, IPv6é Prefix, 


Autonomous System Number, and LSP-ID. This document specifies the 
following new ER-Hop TLV Type: 


0x0805 L2 PW Address of Switching Point 
ER-Hop TLV 
Details of the ER-Hop semantics are defined in Section 3.4. 
3.4. ER-Hop Semantics 


This section describes the various semantics associated with the 
ER-Hop TLV. 


3.4.1. ER-Hop Type: IPv4 Prefix 


The semantics of the IPv4 ER-Hop TLV Type are specified in [RFC3212], 
Section 4.7.1. 


3.4.2. ER-Hop Type: IPv6 Prefix 


The semantics of the IPv6 ER-Hop TLV Type are specified in [RFC3212], 
Section 4.7.2. 
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3:64, 63% 


ER-Hop Type: L2 PW Address 


ng December 2014 


The semantics of the L2 PW Address ER-Hop TLV Type, which contains 
the L2 PW Address derived from the Generalized PWid Forwarding 
Equivalence Class (FEC) AII Type 2 structu 
are as follows. 


Dutta, 


0 al 
OL 23 Ai ngi FBO OL 23. AS. O78 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|u|F| ER-Hop Type 
+-4-4-4-4-4-4-4-4-4+-4-4-4-4-4-4-4-4-4-+ 
|L] Reserved 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+ 
| AII Type=02 | Length | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Global ID (contd. ) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Prefix (contd. ) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| AC ID | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+ 


These bits MUST be set to zero an 
[RFC5036] followed when the TLV i 
receiving node. 


Type 
A fourteen-bit field carrying the 
L2 PW Address, Value = 0x0805. 


Length 
Specifies the length of the value 


L Bit 
Set to indicate a loose hop. 
Cleared to indicate a strict hop. 


Reserved 
Zero on transmission. Ignored on 


PreLen 


Prefix Length 1-96 (including the 
Prefix, and AC ID fields). 
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re as defined in [RFC5003], 


2 3 
9012345678901 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Length 18 | 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| PreLen | 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Global ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Prefix | 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 

AC ID | 
-+-+-+-+-+-+-+-+-+-+-+-+-+ 


d the procedures of 
s not known to the 


value of the ER-Hop 3, 


field in bytes = 18. 


receipt. 


length of the Global ID, 


[Page 5] 


RFC 7392 MS-PW Explicit Routing December 2014 


4. 


ais 


All other fields (AII Type, Length, Global ID, Prefix, and AC ID) 
define the L2 PW Address and are to be set and interpreted as 
defined in Section 3.2 of [RFC5003]. 


Explicit Route TLV Processing 
Next-Hop Selection 


A PW Label Mapping message containing an Explicit Route TLV specifies 
the next hop for a given MS-PW path. Selection of this next hop by 
the ST-PE or S-PE inserting the ER-Hop TLV may involve a selection 
from a set of possible alternatives. The mechanism for making a 
selection from this set is implementation specific and is outside the 
scope of this document. The mechanism used to select a particular 
path is also outside the scope of this document, but each node MUST 
determine a loop-free path if it is to signal the MS-PW. [RFC6073], 
Section 7.6 provides a mechanism by which a node can check that the 
path taken by an MS-PW does not include loops. 


As noted in Section 1, in many deployments the ST-PE will not have a 
view of the topology of S-PEs and so the path will need to be 
supplied from a management application. 


If a loop-free path cannot be found by an ST-PE or S-PE, then a node 
MUST NOT attempt to signal the MS-PW. For an S-PE, if it cannot 
determine a loop-free path, then the received Label Mapping message 
MUST be released with a status code of "PW Loop Detected" as per 
Section 4.2.3 of [RFC7267]. 


To determine the next hop for the MS-PW path, a node performs the 
following steps. Note that these procedures assume that a valid S-PE 
address has been assigned to the node, as per Section 3.1, above. 


1. The node receiving the Label Mapping message that contains an 
ER-TLV MUST evaluate the first ER-Hop. If the L bit is not set 
in the first ER-Hop and if the node is not part of the abstract 
node described by the first ER-Hop (i.e., it does not lie within 
the prefix as determined by the prefix length specified in the 
ER-Hop TLV), it has received the message in error. Therefore, 
the node MUST reply with a Label Release message with a "Bad 
Initial ER-Hop Error" (0x04000004) status code. If the L bit is 
set and the local node is not part of the abstract node described 
by the first ER-Hop, the node selects a next hop that is along 
the path to the abstract node described by the first ER-Hop. If 
there is no ER-Hop TLV contained in the ER-TLV, the message is 
also in error, and the node SHOULD return a "Bad Explicit Routing 
TLV Error" (0x04000001) status code in a Label Release message 
sent to the upstream node. Note that this statement does not 
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preclude a Label Mapping message with no ER-TLV. If a Label 
Mapping message with no ER-TLV is received, then it MUST be 
processed as per [RFC7267]. 


If there are no further ER-Hop TLVs following the first ER-Hop 
TLV, this indicates the end of the explicit route. The Explicit 
Route TLV MUST be removed from the Label Mapping message. This 
node may or may not be the end of the PW. Processing continues 
as per Section 4.2, where a new Explicit Route TLV MAY be added 
to the Label Mapping message. 


If a second ER-Hop TLV does exist, and the node is also a part of 
the abstract node described by the second ER-Hop, then the node 
deletes the first ER-Hop and continues processing with step 2, 
above. Note that this makes the second ER-Hop into the first 
ER-Hop for the iteration for the next PW segment. 


The node determines if it is topologically adjacent to the 
abstract node described by the second ER-Hop. That is, it is 
directly connected to the next node by a PW control-plane 
adjacency. If so, the node selects a particular next hop that is 
a member of the abstract node. The node then deletes the first 
ER-Hop and continues processing as per Section 4.2, below. 


Next, the node selects a next hop within the abstract node of the 
first ER-Hop that is along the path to the abstract node of the 
second ER-Hop. If no such path exists, then there are two cases: 


A. If the second ER-Hop is a strict ER Hop, then there is an 
error, and the node MUST return a Label Release message to 
the upstream node with a "Bad Strict Node Error" (0x04000002) 
status code. 


B. Otherwise, if the second ER-Hop is a loose ER Hop, then the 
node selects any next hop that is along the path to the next 
abstract node. If no path exists within the MPLS domain, 
then there is an error, and the node MUST return a Label 
Release message to the upstream node with a "Bad Loose Node 
Error" (0x04000003) status code. 


Finally, the node replaces the first ER-Hop with any ER Hop that 
denotes an abstract node containing the next hop. This is 
necessary so that when the explicit route is received by the next 
hop, it will be accepted. 


Progress the Label Mapping message to the next hop. 
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4.2. Adding ER Hops to the Explicit Route TLV 


After selecting a next hop, the node MAY alter the explicit route in 
the following ways. 


If, as part of executing the algorithm in Section 4.1, the Explicit 
Route TLV is removed, then the node MAY add a new Explicit Route TLV. 


Otherwise, if the node is a member of the abstract node for the first 
ER-Hop, then a series of ER Hops MAY be inserted before the First ER 

Hop or the first ER-Hop MAY be replaced. Each ER Hop in this series 

MUST denote an abstract node that is a subset of the current abstract 
node. 


Alternately, if the first ER-Hop is a loose ER Hop, an arbitrary 
series of ER Hops MAY be inserted prior to the first ER-Hop. 


5. IANA Considerations 


RFC 5036 [RFC5036] defines the LDP TLV name space, which is 
maintained by IANA, in the LDP "TLV Type Name Space" registry. TLV 
types for the Explicit Route TLV, the IPv4 Prefix ER-Hop TLV, and the 
IPv6 Prefix ER-Hop TLV are already defined in this registry. 


IANA has assigned a further code point from the IETF consensus 
portion of this registry as follows: 


TLV Type Value Reference 
L2 PW Address of Switching Point 0x0805 This Document 
6. Security Considerations 


This document introduces no new security considerations beyond those 
discussed in [RFC5036], [RFC4447], and [RFC7267]. The security 
considerations detailed in those documents apply to the protocol 
extensions described in this RFC. 


As with [RFC7267], it should be noted that the path selection 
mechanisms specified in this document enable the network to 
automatically select the S-PEs that are used to forward packets on 
the MS-PW. Appropriate tools, such as the Virtual Circuit 
Connectivity Verification (VCCV) trace mechanisms specified in 
[RFC6073], can be used by an operator of the network to verify the 
path taken by the MS-PW and therefore be satisfied that the path does 
not represent an additional security risk. 
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